Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

["David A. Cooper" <[e-mail]>]

I have some concerns about the bindingRequest attribute.

Section 3.1 says that the signature field in RequesterCertificate 
"provides evidence that the requesting entity owns this certificate." 
However, "the signature field contains a digital signature over 
IssuerAndSerialNumber." So, what evidence does the CA have that the 
requesting entity created the signature and didn't just copy a signature 
that was previously generated by the actual owner of the certificate?

Perhaps a solution that would produce stronger evidence would be for the 
signature field to contain a digital signature over a SEQUENCE of 
<domain separation string>, <information about other certificate>, and 
<subject public key that appears in this CSR>. The <domain separation 
string> could be some simple string such as "CSR bindingRequest" that 
would provide an extra layer of assurance that the signature was created 
for this purpose.

Given that the "RA should only allow previously issued certificate(s) to 
be indicated in the bindingRequest attribute, the  <information about 
other certificate> could be the other certificate rather than just one 
piece of it (e.g., issuerAndSerialNumber or subjectPublicKeyInfo). This 
would avoid concerns such as those expressed by Ryan. The bindingRequest 
attribute could still just include certID, as that field is just a hint 
to help the RA and CA identify the correct certificate. Similarly, the 
BoundCertificates extension could contain hash of Certificate rather 
than hash of IssuerAndSerialNumber.

For the BoundCertificates extension, is there any reason to allow a 
different hash algorithm to be used for each bound certificate? If not, 
then a few bytes could be saved in the case in which the extension 
includes more than one hash by changing to syntax to:

    BoundCertificates ::= SEQUENCE {

             hashAlgorithm     AlgorithmIdentifier,

             hashValues          SEQUENCE of OCTET STRING

    }

A few more bytes could be saved by requiring the hash algorithm to be 
same as the one used to sign the certificate.

On Tue, Mar 22, 2022 at 7:11 [e-mail]  wrote:
> Could you explain the rationale a bit more for the IssuerAndSerialNumber
> construction?
>
> It won't necessarily unambiguously identify a certificate, in the absence
> of a global directory. Within a multi-stakeholder PKI (like those deployed
> on the Internet today), it's possible for two distinct entities to have the
> same encoded issuer value, but be in possession of distinct keys. The path
> algorithms involved in X.509 and PKIX are able to resolve this (by virtue
> of signature checking to resolve which issuing CA), which also applies to
> OCSP responses, but it seems like it wouldn't apply here.  Broadly, the
> assumption of X.509v3 that Issuer and Serial Number would be globally
> unique and unambiguous didn't hold, as previous communications in the IETF
> with the ITU revealed [1][2][3], and that Distinguished Names aren't, well,
> Distinguished. Is there reason not to use a stronger binding (e.g. the hash
> of the certificate being referenced)?
>
> If two certificates, A and B, both identify the same Subject ("Subject
> Foo"), but with different keys and numbering schemes, it seems that if a
> bound certificate was issued to entity C, with IssuerAndSerial of "Subject
> Foo":1 (referring to A), that B could issue a malicious certificate bearing
> that same serial number, and have it be accepted as legitimate for C.
>
> That said, I do feel I must be missing an important use case, because I'm
> not fully sure I see the utility in this. Is it fair to say that the
> assumption is that both certificates (the original and the bound
> certificate) are participants in the same PKI hierarchy and same set of PKI
> policies? If they weren't, it seems like the issuance of the
> BoundCertificate may introduce operational considerations for the
> renewal/replacement of the target/original certificate, in that replacement
> of the original would necessitate issuing a new bound certificate. Wouldn't
> that unintentionally affect the security considerations/agility of the
> target/original certificate, in unanticipated and perhaps harmful ways?
> Minimally, it seems such chains of binding would have to be ordered from
> "slowest to fastest to replace", to mitigate, and that seems like a
> relevant security consideration.
>
> [1]https://www.ietf.org/proceedings/70/minutes/pkix.htm
> [2]https://www.ietf.org/proceedings/70/slides/pkix-4.pdf
> [3]https://datatracker.ietf.org/liaison/375/
> On Tue, Mar 22, 2022 at 2:16 [e-mail]  wrote:
>
> > Hi LAMPS,
> >
> >   Two new drafts related to PQ migration are available here (note- these
> > drafts are an update to the talk we gave at IETF112 in November) :
> > https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/
> >  and
> > https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/
> >
> >
> >
> > The noncomposite-hybrid-auth-00 draft is an informational draft that gives
> > a general overview of hybrid authentication, and details the solution space
> > of what we are calling non-composite type hybrid solutions for
> > authentication.
> >
> > The cert-binding-for-multi-auth-00 draft defines a new CSR attribute,
> > bindingRequest, and a new X.509 certificate extension, BoundCertificates,
> > which together provide additional assurance that multiple certificates
> > (used in non-composite hybrid authentication) each belong to the same end
> > entity.
> >
> >   Please feel free to provide any comments and feedback!
> >
> >   Regards,
> >   Alie Becker + coauthors Rebecca Guthrie, Mike Jenkins
> >
> >   ----
> >   Alison Becker, PhD
> >   Center for Cybersecurity Standards
> >   National Security Agency
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
> >