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

["[e-mail]" <[e-mail]>]

Thanks for the comments, we appreciate the technical feedback!

We are certainly open to strengthening the signature field to include better assurance as you suggested, a string including purpose is a great idea to ensure the signature is genuine for the attribute. We initially considered including the other certificate instead of just IssuerAndSerialNumber, so we can revisit this idea as well.

For the hash algorithm, we included the algorithm identifier simply to allow for flexibility, but there isn't any particular reason we can't require it to be the same as the one used to sign the certificate.

-Alie
________________________________
From: Spasm <[e-mail]> on behalf of David A. Cooper <david.cooper=[e-mail]>
Sent: Wednesday, March 23, 2022 2:27 PM
To: [e-mail] <[e-mail]>
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs


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 PM [e-mail]<mailto:[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<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fminutes%2Fpkix.htm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=u3Knrx1AW%2F8VqQOjV6G2isyCbS8rq%2FFotOplyDAFT2o%3D&reserved=0>
[2] https://www.ietf.org/proceedings/70/slides/pkix-4.pdf<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F70%2Fslides%2Fpkix-4.pdf&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CojWfH2wwBkDvmHO6B0fWtzZ62xF0g%2FGB1iDsKBRiSE%3D&reserved=0>
[3] https://datatracker.ietf.org/liaison/375/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fliaison%2F375%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=etZP3Ulv4RfN3L6RWwwxyxOzSq6RMI9W%2BfeLGn0tIUQ%3D&reserved=0>


On Tue, Mar 22, 2022 at 2:16 PM [e-mail]<mailto:[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/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JoHwsnMUUsD2FKBqbocRAsA0jDfNscZFYK8%2Fb2kYrF0%3D&reserved=0>
>  and
> https://datatracker.ietf.org/doc/draft-becker-guthrie-noncomposite-hybrid-auth/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-noncomposite-hybrid-auth%2F&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0DqS2Oju1PgFBzGThrJ7kYd4g3z60b3RloGhk09EuwI%3D&reserved=0>
>
>
>
> 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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Caebecke%40uwe.nsa.gov%7C8c562b396ece4466548908da0cfad77a%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C637836569507726440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vVfjXUcYzap3wv3zGOQepKNlAhg9TU7xCuIlIG5tTXI%3D&reserved=0>
>