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

[Martin Rex <[e-mail]>]

Nelson B Bolyard wrote:
> 
> > 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.

The criticality is on the entire SAN extension, not on a particular name,
and the critically is usually visible only to the PKI part of the software
stack.  Apps don't care, and should not have to--in particular,
when they're seperate from the PKI stuff by several layers of abstractions.

If there is an existing SPKM-like GSS-API mechanism that uses
Subject DNames at the GSS-API level, what should it do when
encountering a cert with a subjectAltName marked critical?

The two possibilities are either choke on it or ignore it.
The PKI software underlying this GSS-API might recognize
subjectAltNames, just that the GSS-API mechanism wrapper above
might not be looking at/form them at all.


There is at least one partner who has built a gssapi-mechanism
with OpenSSL, wrapping SSL-records into GSS-API tokens.



One thing that I find particularly irritating in -08 is that
it completely ignores a much more secure authentication
scheme for servers, by clients knowing the entire subject DName
of a certificate rather than matching only a single
name component.

   4.2. Constructing an Ordered List of Reference Identifiers

   o  The list MUST include a DNS-ID.  A reference identifier of type
      DNS-ID can be directly constructed from a fully-qualified DNS
      domain name that is (a) contained in or securely derived from the
      inputs (i.e., the source domain), or (b) explicitly associated
      with the source domain by means of user configuration (i.e., a
      target domain).

  [...]

      Security Note: A client MUST NOT construct a reference identifier
      corresponding to Relative Distinguished Names (RDNs) other than
      the Common Name and MUST NOT check for such RDNs in the presented
      identifiers.

Comparing the full DName is always more secure than comparing
only CN-ID, so this Security Note is factually flawed.

In that respect, rfc-2818 is much more reasonable:

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
   in the middle attacks.



>
> >> 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.

Personally, I count an underexplained SHOULD NOT as an imperative,
about as much as you appear to be assuming the presence of
DNSName SAN name constraints to be an imperative.

There is absolutely no problem whatsoever with how reasonable CAs use
and issue Server-Certs with CN-ID, and similarly, there is absolutely
no problem whatsoever with clients matching CN-IDs.


The general approach of rfc-2818 is *MUCH* more reasonable.  Instead
of lamenting on CN-ID, it simply declares them as deprecated and
suggests how to do server endpoint identification in the future.
In particular it does NOT mess around with existing practice
(in documentation, in implementations and in CA practices).


Describing how CAs should issue Certs with DName-SANs for a certain
purpose is OK.  Describing potential security issues and implementation
inconsistencies with CN-ID is also OK.  But trying to change rules
for Subject DName to something that differs considerably from
existing documentation, existing implementations and existing practise
is inappropriate.  After all, CN-ID has been deprecated for many years.



> 
> 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".

Implementing name constraints for DNSName SANs is optional.  

And an subordinate CA that wants to issue Certs using CN-IDs for
bypassing DNSName SAN Name constraints is certainly not going to
be stopped by a "MUST NOT issue" guidance in a BCP document.
A subordinate CA is more likely to be held responsible for
issuing certs not incompliance with the policies of it's parent CA
than by ignoring a SHOULD NOT in some RFC document.

The only behaviour clearly causing harm are some commercial CAs
which disclaim libabilities for blindly copying unvetted DName
components from the CSR they receive into the Certs they issue.


> 
> > 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.)

Why?  You mean that there are CAs that issue Server certs _without_ SANs
and CN-IDs that you have to be afraid of?  Why would you be less afraid
if they issued certs with DNSName SANs, and why do you trust such CAs
in the first place?


> 
> >> 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.

Most software on top of OpenSSL checks CN-IDs only.

> 
> > 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?

What you are suggesting is involuntary euthanasia.

I violently oppose the creation of interop problems in order to
discriminate against an installed base, especially when there is
no problem with the existing scheme to have old and new coexist
peacefully together.


> 
> >> 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.


So you are abusing Firefox to protect an inter-CA business model?

For the end user this is completely irrelevant.



> 
> 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).

HUH?  Name constraints work only within one single hierarchy.  As soon
as you have two independent trusted Roots, name constraints no longer
work.  Browsers come preloaded/pretrusted with ~40 independent Roots.

-Martin