Re: [certid] Need to define "most specific RDN"

[Nelson B Bolyard <[e-mail]>]

On 2010-07-16 17:54 PDT, Martin Rex wrote:
> But I have a problem with words in a BCP that
> are in clear violation of rfc-2119 section 6 last sencence
> with the potential to cause interop problems and entirely without
> a cause.

Fair enough, but I challenge your implicit assertions that there is any
"clear violation" or that they are "without cause".

> What is the purpose of marking SAN critical other than having a
> number of peers choke on it and reject it?  It's hardly make a
> cert more understandable.  An implementation of PKI has no control
> over what exactly an application does with a SAN.

It is obviously to ensure that any relying party relies on the content
of the SAN.  An issuer DOES have control.  It ensures that the relying
party will NOT rely on the cert if it does not grok the SAN.

>> 3) Make strong recommendations to stop using CN-IDs in subject
> 
> Really bad idea, completely unnecesary and clear violation of
> rfc-2116 section 6.

Baloney.  May I suggest you re-read that section of the RFC you most
frequently cite?  "Making strong recommendations" is not the same as
"Imperative" or "MUST" and you know it.

But further, section 6 allows imperatives for "behavior which has
potential for causing harm".  Allow subordinate CAs to issue certs that
bypass the name constraints placed on them is most definitely "behavior
which has potential for causing harm".

> Im pretty sure that every one which strongly cares about this can
> make his client ignore CN-IDs when at least one DNSName SAN is
> present, so 2) is perfectly sufficient.

Only after CAs stop issuing certs without SANs.  I read Paul's message as
saying that Digicert is issuing certs without SANs.  (Paul, please correct
me if that is mistaken.)

>> 4) Stop using server-IDs in common names experimentally 

A great idea.  Especially if the only affected products are really old cell
phones that cannot handle modern web sites anyway.  Continue to have special
wifi.domain.TLD web sites for them, and let the rest of the Internet move
ahead.

> All the big players have implemented IPv6 and tested interop.
> Why don't we shutdown the entire IPv4 internet to force the
> users to use IPv6? 

Martin, you oppose experimentation?
Do you want to live in the past forever?

>> On the topic of name constraints: What if there are ways to push Name
>> Constraints forward without necessarily having to wait for all legacy
>> clients to die and all the niche clients to become compatible?  

Firefox already applies DNS name constraints to DNS names in SANs, and
has for years.  In a forthcoming version of Firefox, DNS name constraints
WILL be applied to last Subject CN under the following circumstances:

- The cert chain being verified is being verified for the purpose of being
an SSL/TLS server certificate
- the server cert has no SAN extension, or no DNS names in its SAN extension

(in other words, under the same circumstances in which we would use the
last Subject CN as a CN-ID for cert name matching purposes).

The value of these name constraints is that they will enable CAs to issue
subordinate CA certs to corporations without any fear that those
corporations will issue false certs for their competitors.

They also allow relying parties to constrain names in entire PKI trees
subordinate to certain national CAs, thereby greatly reducing vulnerability
to the compelled issuance of certificates for domains outside that CA's
national country code domain(s).  Without doubt, the threat of compelled
issuance has been the single biggest threat to public confidence in PKI
to have come along in years, and name constraints are one of the few ways
we have of combating that threat.  So, don't dismiss it lightly.