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

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 PM aebecke@uwe.nsa.gov <aebecke=
40uwe.nsa.gov@dmarc.ietf.org> 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
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>