Hi Jim, 802.1AR has some very long lived certificates out there (no expiration date) because they’re burned into the device. Now, not everything needs to deal with AR certs, and they’re not meant for normal web usage. This group is focused on web usage, but rather than scope Rich’s draft to that, my suggestion is that we simply take the reality into account, and note that there are going to be places where such certs exist for quite a while, and that some implementations will have to deal with them. To do otherwise ignores reality.
Conveniently, AR cert usage in the wild is generally constrained, and people shift over to deployment certificates. That’s what draft-ietf-bootstrapping-keyinfra and RFC 8366 are for. There are surely other uses of AR that we’re not aware of, and there are surely other uses of long lived certificates that we are also not aware of. The verifiers in these cases are likely to know when they need to interact with such systems. So either we give that sort of advice or they’ll simply ignore us, because otherwise their systems will simply break. Eliot > On 19 Apr 2021, at 22:55, Jim Fenton <fen...@bluepopcorn.net> wrote: > > I’m probably joining in the middle of this conversation, but please be > patient with me: > > On 19 Apr 2021, at 10:48, Eliot Lear wrote: > >> Hi Rich, >> >> A few of us just had this discussion in another context. Try this: >> >> CAs MUST populate a SAN. >> Verifiers MUST use a SAN if present. >> Verifiers MUST reject certificates without a SAN by default. > > I don’t understand what “by default” means here; it seems to conflict with > the MUST. Of course using CN to indicate the subject of the certificate > hasn’t been good practice for 10 years or so, but this requirement seems to > run counter to the principle of being liberal in what you accept (with the > obvious exception of things that create a security problem, but I don’t think > that is the case here). What is the problem that this requirement is solving, > other than eliminating a few lines in certificate verification code? > >> Verifiers MAY be configured to accept certificates without SANs when very >> long lived certificates are expected to be encountered. > > This must be the exception to the previous bullet. But I would expect the > requirement to be based on the issue date of the certificate, not its > lifetime. How does a verifier know in advance what to expect? > > Are CAs issuing certificates with freeform text in their CN fields, is that > the problem? > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
