Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    ok will cut a new release
    Tony Arcieri
    @tarcieri
    on a completely different matter...
    @str4d it’d be cool if name here were Option<&’a str>
    and if it were, omit CN entirely
    str4d
    @str4d
    Is that the right layer?
    making issuer and subject optional
    Hm... maybe not
    Is SEQUENCE OF what allows it to be empty?
    Tony Arcieri
    @tarcieri
    let me ask someone, heh
    also Thomas Pornin would know. I just asked Sleevi...
    str4d
    @str4d
    Going straight to the authoritative root :P
    Tony Arcieri
    @tarcieri
    haha indeed
    he says empty Subject is technically valid per RFC 5280 but Apple has been flaky on support
    also: your CN-encoding code seemingly doesn't apply the 64-char limit
    str4d
    @str4d
    Ooh, good point
    Tony Arcieri
    @tarcieri
    so I think the answer is empty subject is possible but CN is presently required by the CA/B rules (but not RFC 5280)
    empty subject also requires a critical SAN
    wonder if there are SPIFFE identifiers for humans or something
    str4d
    @str4d
    x509 0.1.2 enforces the CN length requirement.
    Tony Arcieri
    @tarcieri
    cool
    str4d
    @str4d
    Opened str4d/x509.rs#1 for the optional CN.
    Tony Arcieri
    @tarcieri
    :thumbsup:
    str4d
    @str4d
    Nice! Horribly unreadable, but nice!
    Tony Arcieri
    @tarcieri
    hahaha
    str4d
    @str4d
    "Let's just pretend that an 8-bit number is a 1- or 2-bit number and hope our generation code doesn't overflow"
    I don't know whether the code is assuming that a cast to fiat_p256_i2 will mask out all but the lowest 2 bits, but it sure as hell isn't doing that.
    str4d
    @str4d
    @tarcieri I've sketched out a rough API for RSA signatures as a starting point for discussion: RustCrypto/RSA#34
    Tony Arcieri
    @tarcieri
    nice, looking now
    str4d
    @str4d
    Slightly slower having this conversation in the GH thread, but this is all very valuable :D
    Tony Arcieri
    @tarcieri
    yup
    it’s an annoying set of tradeoffs to square. unfortunately people seem dissatisfied with the solution of “focus on having one high-quality set of digest algorithms” :cry:
    which I can kind of get. there are the issues of architecture-specific SHA-NI-style instructions and whether e.g. the sha256 crate should support every variant of those under the sun or not
    str4d
    @str4d
    Something I realised while implementing RandomizedDigestSigner (which turns out I definitely need):
    It's unfortunate that there are two distinct use cases for the trait: for randomized signatures, and for deterministic but blinded signatures.
    Tony Arcieri
    @tarcieri
    I’d also be okay with splitting those use cases into separate traits...
    str4d
    @str4d
    Yeah; it's not clear to me how a user should distinguish between the two.
    This is also similar to the issue of the RSA NoneDigest problem
    Tony Arcieri
    @tarcieri
    RSA: why we can’t have nice things :weary:
    str4d
    @str4d
    (i.e. whether signature::Signer is for arbitrary-length messages only)
    Tony Arcieri
    @tarcieri
    that’s the intent, although for PKCS#1v15 I think it’d be fine to error on the message being the wrong length
    I guess overlong is the main error case?
    str4d
    @str4d
    This is my current thinking for strategy:
    • Signer is for arbitrary-length messages, and does whatever is appropriate to sign them. This fits with the auto-derive to DigestSigner underneath.
    • DigestSigner is the "main" interface; for RSA we impl Digest for NoneDigest to handle the directly-signed message case.
    • RandomizedDigestSigner is the interface for randomized signatures.
    • BlindedDigestSigner is an almost-identical interface (just trait method names are different) which is for deterministic signatures with blinding.
    "Overlong" is fine if Signer is only intended for directly-signing messages, but my concern is that confuses users given that other impls of Signer call through to DigestSigner due to the derive.
    Tony Arcieri
    @tarcieri
    are you saying the Signer and DigestSigner relationship is reversed versus… every other signature algorithm in the universe that uses Fiat-Shamir?