Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

[Tomas Gustavsson <[e-mail]>]

Hi,

In my experience It is not true that some RFCs do not affect many users. If there is a RFC out there, even with only a few users there is an associated eco system costs with it.
CA software will be asked to implement it, TLS stacks, validating APIs, etc.
In addition, with multiple users there will be multiple interpretations of anything that is not explicitly called out in the RFC, for example how to validate aspects of the new field. This leads to on-going discussions and development and cost, and even customer wanting to violate the RFC for their own purposes. It happens all the time.

With this I just want to say that there is no RFC that does not impact the eco system, let's not tell ourselves that it can be "free". The question is: What is the cost, and is it worth it?

I read through the draft again and have a couple of technical questions/comments. Not considering other email discussions here, so there may be duplications, but just reading the current draft.

1. The functionality specifies a CSR extension, it names it coming from the RA but typically it comes from the subscribers, allowing POP to be used.  So the RA is in practice just a "proxy" for the CSR itself, possibly doing different types of validation, but the RA can not add extensions to the CSR, except in the case of CRMF, using "RA Verified" POP. This is a unclear from the draft.
2. The draft asks the CA to fetch files (CMS certs-only structure in DER format) from a user provided location (URL in the CSR). This is often not allowed directly by the CA. This has potential to significantly affect CA architecture and implementations. I think this part needs more evaluation. I can see a lot of potential practical issues here.
3. In section 3.1, the draft mentions "signed using the signature algorithm and private key associated with the certificate identified by the certID field" and "use the ECC KE private key". How about certificates with PQC KEM keys?
4. In section 4.1 it says "The algorithm used to hash the certificate in the RelatedCertificate extension MUST match the hash algorithm used to sign the certificate that contains the extension.".
The notion of same hash algorithm smells "classic" signature algorithms like SHA245WithRSA/ECDSA where it is obvious. How about Ed25519/448 or PQ algorithms where the hash algorithms used are kind of "hidden" inside the signature algorithm? Seems non-trivial for CAs and validators with the need to externalize knowledge of signature algorithm internals, being non-agile as algorithms change or update. I don't think OpenSSL or Bouncy Castle provides Signature.getHashAlgorithm as part of the API. In this aspect the SCVP structure mentioned that mentions the hash algorithmIdentifier seems a more agile approach, even if there are more bytes used.
5. Section 4.1 says that the CA "MUST ensure that all certificates are intended for the same use case", but how is outside of the scope of the document. This is a potential sink hole for implementors. Why leave it out of scope? If out of scope how to do it, it is better to not require it at all since it doesn't really mean much.
6.  Section 4.2 basically modifies the RFC5280 Certificate Path Validation. It is only SHOULDs. If the validation client wants to use the extension, the validation steps should be MUST should it not?
7. About use cases. Technically I'd guess you can say that the draft creates a "POP" that the entity has the private key of both certs. The use cases mentioned in the draft are CMS, S/MIME, TLS and IPSec. From the brief description in the Overview it's not clear (to me) what the benefits are from the already built in mechanisms in those protocols. It just says "A validator that prefers multiple authentication types may be assisted by the inclusion of relevant information in the signer's certificate". Some specification of this would be useful in the draft? In for example TLS, I'd expect each certificate to have to be validated by CA/B Forum validation guidelines independently.

Cheers,
Tomas

________________________________
From: Spasm <[e-mail]> on behalf of Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Sent: Sunday, October 23, 2022 5:00:58 AM
To: Kampanakis, Panos <kpanos=[e-mail]>; Michael Jenkins <[e-mail]>
Cc: Russ Housley <[e-mail]>; LAMPS <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [e-mail] with any questions.


It looks like there’s a legitimate use case for this extension, and a “Community Of Interest” that wants it. More importantly, people/organizations/CAs that don’t plan or want to support it, don’t need to (you see it – ignore it). So, no skin off anybody’s back to adopt it.



So far, I haven’t heard any technical reasons why this extension would be “universally bad”. Just stuff like “it does not make sense for my organization/business”, or “if I support it – it would interfere with my <whatever>”. To all of which a simple answer is “then don’t”. Let those who care, support it and use it.



The way I read this draft, it says “if you need to do explicit certificate binding, do it this way to be interoperable”. Which is fine with me – nobody would be forced to implement or support this extension.



So, I vote to adopt it for the above reasons.



> Mike said:

> So, I think Panos' question to Rebecca / Allie / Michael is: what is the advantage of relating two certs by an

> extension if they are already "related" by virtue of having the same issuer and DN or the same SAN?



I doubt they’d be related by the same issuer – but IMHO it’s reasonable in general to expect the same DN and/or SAN. But I can imagine situations when this would not be the case, and the only way to ascertain the binding would be this extension.



> Is there a case where some mischief would be caught by the Related Certs Extension that would otherwise be un-caught?



See above – you assume DN and SAN (and/or SAN?) would have to be the same, I think this assumption won’t always hold.



TNX

--

V/R,

Uri



There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare





From: Spasm <[e-mail]> on behalf of "Kampanakis, Panos" <kpanos=[e-mail]>
Date: Saturday, October 22, 2022 at 22:22
To: Michael Jenkins <[e-mail]>
Cc: Russ Housley <[e-mail]>, LAMPS <[e-mail]>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01



I understand the draft. I had shared some technical concerns for issuers that would need to add the Related Cert Extension which had not been addressed.



But let’s say that the extension does not mean that the issuer has to do any additional checks which some are suggesting has pitfalls. Let’s say that as you are suggesting, the issuer just needs to check two signatures to confirm the requester has the private keys for both related public keys. Why do we need the extension anyway? The relation of the two certificates comes from the identity (CommonName or maybe some SANs) which should be the same.



Why not avoid the hassle of standardizing the extension in LAMPS? Entity X can get two certs issued independently. Then it sends them both along with two chains and two signatures in the TLS handshake. The verifier needs to verify both signatures and chains independentlyand confirm the identity in both certs (e.g. CN, SAN) match. In that case you only need to update TLS  in the TLS WG and IKEv2 in the IPSECME WG and you don’t need to update X.509.





From: Spasm <[e-mail]> On Behalf Of Michael Jenkins
Sent: Saturday, October 22, 2022 11:33 AM
To: Kampanakis, Panos <kpanos=[e-mail]>
Cc: Russ Housley <[e-mail]>; LAMPS <[e-mail]>
Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



If there are no technical showstoppers, I don't understand the objection.



Mike and John have a well defined scheme, for which they have prototypes and apparent customers. So that will exist.



On the other hand, singleton certificates will also exist. The US DoD will have oceans of them. So will companies with limited resources that will balk at the idea of being sold something they already have bolted to something there's apparently lack of confidence in. Singleton certificates will exist irrespective of our draft; we are not creating a necessary precondition.



All our draft does is provide an indication of assurance that one certificate is related to another. The specific relation is that the entity controlling the private key in one certificate also controls the private key in another. Those certificates exist separately. The relative context of those certificates (validity period, etc) would have to be part of a transition plan.



If you don't like the mechanism, if you don't understand it, if it doesn't fit with your transition scheme, you don't have to implement it, or buy it. If you encounter it, you can ignore it. On the other hand, if it fits with your transition scheme, it can add some assurance. This is explained in the overview of the draft.



Mike Jenkins

NSA-CCSS



On Wed, Oct 19, 2022 at 11:03 PM Kampanakis, Panos <kpanos=[e-mail]<mailto:[e-mail]>> wrote:

Hey Russ,
I have not been convinced either. My details for the operational challenges this draft would bring still remain. Willing to hear more counter-arguments from Rebecca and Mike to address the concerns or discuss it further.


-----Original Message-----
From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Wednesday, October 19, 2022 3:47 PM
To: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Several people spoke for adoption, and several people spoke against adoption.  The I-D authors responded with a response to the concerns that were raise, and no one has responded to the authors.  I would like to hear from the people that spoke against adoption.  Are you swayed by the discussion that has taken place?

Russ


> On Sep 15, 2022, at 11:44 AM, Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:
>
> There has been some discussion of https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cb8455c1f99b94cb7409108dab4a2da36%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638020908836639752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZwLeEbIdSYfQ%2FPFOdf1yl3QotOpM%2B%2BUhMj55rjPmOn4%3D&reserved=0>.  During the discussion at IETF 114, we agree to have a call for adoption of this document.
>
> Should the LAMPS WG adopt “Related Certificates for Use in Multiple Authentications within a Protocol” indraft-becker-guthrie-cert-binding-for-multi-auth-01?
>
> Please reply to this message by Friday, 30 September 2022 to voice your support or opposition to adoption.
>
> On behalf of the LAMPS WG Chairs,
> Russ
>

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cb8455c1f99b94cb7409108dab4a2da36%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638020908836639752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mi%2BvGK6rPLCEzPA0QyU4lAxm5JAwbYmCGc4Uz6LY4zc%3D&reserved=0>
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cb8455c1f99b94cb7409108dab4a2da36%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638020908836639752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mi%2BvGK6rPLCEzPA0QyU4lAxm5JAwbYmCGc4Uz6LY4zc%3D&reserved=0>


--

Mike Jenkins

[e-mail]<mailto:[e-mail]>

443-598-7837