Re: Authority Key Identifier values

Thanks to everyone who replied!

"David A. Cooper" <david.cooper <at> nist.gov> writes:

...
> Note that section 4.2.1.2 states:
>
>      In conforming CA certificates, the value of the
>      subject key identifier MUST be the value placed in the key identifier
>      field of the Authority Key Identifier extension (section 4.2.1.1) of
>      certificates issued by the subject of this certificate.

Aha, that was the text I wanted to find.  My mistake was to look for
it in the section describing AKI.  The text above implicitly specify
what to put in AKI fields; it might make sense to move it to (or say
something similar in) section 4.2.1.1 (on AKI's).  Section 4.2.1.1
currently says:

   The value of the keyIdentifier field SHOULD be derived from the
   public key used to verify the certificate's signature or a method
   that generates unique values.

That is correct for CA certificates, but flawed for EE certificates.
We _did_ derive the AKI from the CA's public key, but everyone agrees
that this is the wrong thing to do.  That sentence, and the absence of
the quoted text above, in section 4.2.1.1, was likely the cause for
our bug.

For those who are interested in more details, the software that

RE: draft-ietf-pkix-srvsan-00

Paul,

The format of DNS names in the dNSName Alt name is limited to ASCII. So there is no choice other than using the
punycode format of an IDN.

Different name forms are allowed to have different encoding, that is nothing new.
So why do you come to the conclusion that the dNSName alt name must have the same format as a service name?
You seem to state that this is an obvious requirement, but it is not obvious to me.

We discussed this in the WG and concluded that there are advantages in using UTF-8 encoding and storing the
service name in a form where it can be printed and displayed. There must be a rationale why we should move
away from this.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Paul Hoffman
> Sent: den 13 januari 2007 00:07
> To: ietf-pkix <at> imc.org
> Subject: RE: draft-ietf-pkix-srvsan-00
>
>
> Greetings again. This document has just gone through IESG review and
> has garnered a bunch of DISCUSS comments. Some of them relate to the
> way that this document handles IDNs.
>

RE: draft-ietf-pkix-srvsan-00

At 5:01 PM +0000 2/1/07, Stefan Santesson wrote:
>Different name forms are allowed to have different encoding, that is 
>nothing new.
>So why do you come to the conclusion that the dNSName alt name must 
>have the same format as a service name?
>You seem to state that this is an obvious requirement, but it is not 
>obvious to me.

It is obvious to me that having different encoding rules for domain 
names is likely to confuse implementers. There is nothing in SRV 
names that make them any different than "regular" domain names.

>We discussed this in the WG and concluded that there are advantages 
>in using UTF-8 encoding and storing the service name in a form where 
>it can be printed and displayed. There must be a rationale why we 
>should move away from this.

I have given mine; you may or may not like it.

--Paul Hoffman, Director
--VPN Consortium

RE: draft-ietf-pkix-srvsan-00

Well,

You could perhaps help straighten one thing out about coding decoding punycode.

Let's say that I encounter a domain name in the form "xn--exmple-cua.com"
This is the punycode equivalent of "exämple.com"

Is there any way the parser can know with 100% certainty if this domain name was intended to be presented as
"xn--exmple-cua.com" or as "exämple.com". Both are valid domain names.
If the name is stored in UTF-8, no parser needs to wonder.

I think your logic is halting in one important aspect. Assuming that UTF-8 to punycode conversion is
simple, deterministic and straight forward, why would it then be confusing to implementers?
If it is not simple, then the value of having the UTF-8 format is even bigger.
If UTF-8 -> punycode is simple, deterministic and widely deployed, while punycode -> UTF-8 is somewhat
more ambiguous, then there is an obvious advantage of storing the dns name part in UTF-8.

Finally, I can't think of any situation where a certificate user would need to match the srvName from a
certificate with a dns name of a certificate. They are not used for comparison with each other, but to be
compared with a data external to the certificate according to local policy.
But even if it was the case, I can't see the serious challenge of having one in punycode and the other in UTF-8.
It really feels like a trivial problem not worth re-opening what was previously agreed.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman <at> vpnc.org]

RE: asn.1 modules in 3280bis

I would like to have the other editors and WG opinion.
If it is positive, then I assume it's a fairly straightforward process if we get to it.

Lets finish this up so we can ship this document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Russ Housley
> Sent: den 29 januari 2007 18:02
> To: Peter Sylvester; pkix
> Subject: Re: asn.1 modules in 3280bis
>
>
> Peter:
>
> RFC 3280 includes two ASN.1 Modules:
>     PKIX1Explicit88, and
>     PKIX1Implicit88.
>
> I have no objection to using three ASN.1 Modules in 3280bis:
>     PKIX1Explicit88,
>     PKIX1Implicit88, and
>     PKIX1Extensions.
>
> I'm sure that you could help the authors figure out which type

Re: asn.1 modules in 3280bis

I'd be marginally against this change, on the basis
that its so late, might be error prone and I'm not
sure that the claimed benefit is significant (don't
most people just comment out one of the colliding
definitions?).

Having said that, if David (who'd do the work) does
want this, I won't object,
Stephen.

Stefan Santesson wrote:
> I would like to have the other editors and WG opinion.
> If it is positive, then I assume it's a fairly straightforward process if we get to it.
> 
> Lets finish this up so we can ship this document.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> 
>> -----Original Message-----
>> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
>> pkix <at> mail.imc.org] On Behalf Of Russ Housley
>> Sent: den 29 januari 2007 18:02
>> To: Peter Sylvester; pkix
>> Subject: Re: asn.1 modules in 3280bis
>>
>>

RE: Sample end entity certificate

Inclusion of optional extensions are optional since they are situation dependent.
What can be recommended in one implementation may be totally redundant in another.

RFC 3280 is not designed to do implementation specific recommendations. For that purpose there are
numerous certificate profile documents aimed at certain usages of PKI.
So what can be recommended in your case, can still be optional in the basic standard.

In this regard, the standard is correct.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of Moudrick M. Dadashov
> Sent: den 15 januari 2007 02:32
> To: Russ Housley
> Cc: ietf-pkix <at> imc.org
> Subject: Re: Sample end entity certificate
>
>
> Russ,
>
> but RFC 2119 also does say:
>
> "OPTIONAL", mean that an item is truly optional. One vendor may choose
> to
> include the item because a particular marketplace requires it or

RE: asn.1 modules in 3280bis

Re: asn.1 modules in 3280bis

At 12:00 PM +0000 2/2/07, Stephen Farrell wrote:
>I'd be marginally against this change, on the basis
>that its so late, might be error prone and I'm not
>sure that the claimed benefit is significant (don't
>most people just comment out one of the colliding
>definitions?).

I agree with Stephen and Sharon. This could easily be an add-on RFC.

--Paul Hoffman, Director
--VPN Consortium

RE: draft-ietf-pkix-srvsan-00

At 10:13 AM +0000 2/2/07, Stefan Santesson wrote:
>Let's say that I encounter a domain name in the form "xn--exmple-cua.com"
>This is the punycode equivalent of "exämple.com"
>
>Is there any way the parser can know with 100% certainty if this 
>domain name was intended to be presented as "xn--exmple-cua.com" or 
>as "exämple.com".

Yes. It is fully described in the IDNA document. Read the section on 
the ToUnicode function.

>Both are valid domain names.
>If the name is stored in UTF-8, no parser needs to wonder.

Of course. This was discussed in detail in the preparation of IDNA. 
It is described in detail in the IDNA specification.

>I think your logic is halting in one important aspect. Assuming that 
>UTF-8 to punycode conversion is simple, deterministic and straight 
>forward, why would it then be confusing to implementers?
>If it is not simple, then the value of having the UTF-8 format is even bigger.
>If UTF-8 -> punycode is simple, deterministic and widely deployed, 
>while punycode -> UTF-8 is somewhat more ambiguous, then there is an 
>obvious advantage of storing the dns name part in UTF-8.

If you think that having domain names in PKIX fields in two different 
formats will not cause any confusion, that's fine. Neither you nor I 
can prove our case. I simply think that one format is better than two.

>Finally, I can't think of any situation where a certificate user 
>would need to match the srvName from a certificate with a dns name 
>of a certificate. They are not used for comparison with each other, 
>but to be compared with a data external to the certificate according 
>to local policy.

...and that data is in Punycode format if it comes from the DNS.

--Paul Hoffman, Director
--VPN Consortium