Subject: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

From: "trans issue tracker" <[email-masked]>
Date: Wed, 17 Dec 2014 16:35:47 -0000

#54: Simplify name redaction

 The name redaction mechanism, as currently defined, does not reveal how
 many labels have been redacted.  This seems unnecessary.  If we're happy
 to reveal the number of redacted labels, then we could simplify the name
 redaction mechanism by...
   - scrapping the "redactedLabels" Certificate extension
 (1.3.6.1.4.1.11129.2.4.6).
   - stating that the literal string "(PRIVATE)" always covers precisely
 _one_ label.

 So for example, if you wanted to redact 3 components, you'd put
 "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the
 Precertificate.

 To reduce bloat, I think we should also change "(PRIVATE)" to "?".
 e.g. "SAN:dNSName=?.?.?.mydomain.com"

 This simplification would make ticket #17 easier to resolve.  i.e. We
 could permit "CN=?.?.?.mydomain.com".

 When I proposed this on the TRANS list back in September, Eran commented:
 "+1 to that - seems like it would significantly simplify the
 implementation of redacted domain name label: The risk of misalignment
 between the values in the extension that counts the number of redacted
 subdomains for each SAN and the actual SANs goes away."

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/54>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Dec 2014 13:16:52 -0500

Rob,

>     - scrapping the "redactedLabels" Certificate extension
I think that indicating how many names have been redacted is a good
simplification.
>     - stating that the literal string "(PRIVATE)" always covers precisely
Since DNS names are case insensitive, I suggest we not represent a reserved
label in uppercase. It may cause some readers to believe that the label is
special because of its case.
>   e.g. "SAN:dNSName=?.?.?.mydomain.com"
Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034,
and RFC 5280 cites 1034 as the normative spec for dNSName syntax in
the subjectAltName extension.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Tue, 23 Dec 2014 14:02:40 +0000

> I think that indicating how many names have been redacted is a good

Thanks Stephen.

> special because of its case.

The private label _is_ "special" though.  :-)

It's intended to be a placeholder for a real label.

> the subjectAltName extension.

I agree that "?" is not a valid DNS label character according to RFC 
1034, but that's actually a useful characteristic here.  If it was a 
valid DNS label character, then it could be mistakenly interpreted as a 
real label rather than as just a placeholder!

"*" isn't a valid DNS label character either, and yet it is commonly 
used in SAN->dNSName fields as a placeholder.

You're referring to this part of RFC5280 Section 4.2.1.6:
   "When the subjectAltName extension contains a domain name system
    label, the domain name MUST be stored in the dNSName (an IA5String).
    The name MUST be in the "preferred name syntax", as specified by
    Section 3.5 of [RFC1034] and as modified by Section 2.1 of
    [RFC1123]."

If one or more labels is a placeholder rather than a real label, then 
IMHO the string is _not_ a "domain name system label".  And therefore, 
the two MUST requirements quoted above don't apply.

Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_ 
"domain name system labels" into SAN->dNSName fields.

Towards the end of Section 4.2.1.6 it says:
   "Finally, the semantics of subject alternative names that include
    wildcard characters (e.g., as a placeholder for a set of names) are
    not addressed by this specification.  Applications with specific
    requirements MAY use such names, but they must define the semantics."

So, as long as we "define the semantics" for our use of "?", I don't 
think we're doing anything wrong.

Do you agree?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online