headers
Denis Pinkas | 1 Feb 2008 12:12
Picon

Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)


A few comments.

(...)

>PKIX will pursue new work items in the PKI arena if working group 
>members express sufficient interest, and if approved by the cognizant 
>Security Area director. For example, certificate validation under X. 
>509 and PKIX standards calls for a relying party to use a trust 
>anchor as the start of a certificate path. 

This is not fully correct. Proposed change:

"For example, certificate validation under X. 509 and PKIX standards 
calls for a relying party to use *one or more* trust anchors and 
optional *additional conditions* as the start of a certificate path".

> Neither X.509 nor extant 
>PKIX standards define protocols for the management of trust anchors. 

This is untrue.

RFC 4210 "PKI Certificate Management Protocols" (CMP) defines data structures 
that allow to change a single trust anchor. The posting of these data structures 
which are certificates allow to change gracefully one trust anchor. These certificates 
may be placed in a directory and can be retrieved using any kind of protocol able 
to obtain ordinary certificates.

Page 9 :
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 2 Feb 2008 17:52

Fwd: draft-ietf-pkix-ecc-subpubkeyinfo-02


So the whole WG can see the comments we received ...

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah <at> tr-sys.de>
>Subject: draft-ietf-pkix-ecc-subpubkeyinfo-02
>To: turners <at> ieca.com, kelviny <at> microsoft.com, dbrown <at> certicom.com,
>         housley <at> vigilsec.com, wpolk <at> nist.gov
>Date: Sat, 2 Feb 2008 01:35:11 +0100 (MEZ)
>
>Hello,
>I also have performed a (rather quick) review of the I-D
>authored by you, draft-ietf-pkix-ecc-subpubkeyinfo-02 .
>
>Here are the textual issues I found and my suggestions for
>additional improvements:
>
>
>(1)  Section 1
>
>The second text paragraph (below the algorithm list) says:
>
>                                               [...].  To promote
>    interoperability, this document indicates which is required.
>
>This is considered ambiguous:
>Do you mean "required to implement", "required to use", or both ?
>
> >From details specified later in the draft, it becomes clear that
>perhaps the former choice had been intended.
>I suggest to clarify this at first place, stating unambiguously:
(Continue reading)

Permalink | Reply | 0 comments |
headers
David A. Cooper | 5 Feb 2008 20:19
Favicon

draft-ietf-pkix-rfc3280bis-11.txt


All,

Yesterday, I submitted draft -11 of 3280bis for posting.  This will, 
hopefully, be the final draft.

As usual, I have posted a diff file highlighting the changes between 
drafts -10 and -11: 
http://www.csrc.nist.gov/groups/ST/crypto_apps_infra/documents/draft3280bis-10todraft3280bis-11_diff.html.

1) Text added to clarify that extensions (extnValue in Extension) in 
must be DER encoded.

2) All references to "RFC 822 name" were replaced with "electronic mail 
address" or "rfc822Name", whichever was more appropriate.

3) All references to "addr-spec" from [RFC 2822] were replaced with 
references to "Mailbox" from section 4.1.2 of [RFC 2821].

4) Text was added to section 4.2.1.4 to provide further guidance on the 
use of the explicitText string from the userNotice policy qualifier:

   The explicitText string SHOULD NOT include any control
   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
   the UTF8String encoding is used, all character sequences SHOULD be
   normalized according to Unicode normalization form C (NFC) [NFC].

5) Text was added to clarify that domain labels in DNS names that appear 
in the dNSName field of subjectAltName may begin with a digit, as is 
permitted by [RFC 1123].
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Hoffman | 5 Feb 2008 23:51

Re: draft-ietf-pkix-rfc3280bis-11.txt


At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>Yesterday, I submitted draft -11 of 3280bis for posting.  This will, 
>hopefully, be the final draft.

Sorry, but there is a technical change that should be made to the 
differences you posted:

>4) Text was added to section 4.2.1.4 to provide further guidance on 
>the use of the explicitText string from the userNotice policy 
>qualifier:
>
>   The explicitText string SHOULD NOT include any control
>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>   the UTF8String encoding is used, all character sequences SHOULD be
>   normalized according to Unicode normalization form C (NFC) [NFC].

If we want all text to be normalized, we want it for both UTFString 
*and* BMPString.

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 5 comments |
headers
Jean-Marc Desperrier | 6 Feb 2008 09:53
Picon
Favicon

Re: draft-ietf-pkix-rfc3280bis-11.txt


Paul Hoffman wrote:
> At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>> 4) Text was added to section 4.2.1.4 to provide further guidance on 
>> the use of the explicitText string from the userNotice policy qualifier:
>>
>>   The explicitText string SHOULD NOT include any control
>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>   the UTF8String encoding is used, all character sequences SHOULD be
>>   normalized according to Unicode normalization form C (NFC) [NFC].
> If we want all text to be normalized, we want it for both UTFString 
> *and* BMPString.
Would it not be better to simply deprecate BMPString ?
(as well as UniversalString if referenced somewhere)
Permalink | Reply | 4 comments |
headers
Peter Sylvester | 6 Feb 2008 11:35
Picon
Picon
Favicon

Re: draft-ietf-pkix-rfc3280bis-11.txt


TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                           -- if present, MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                           -- if present, MUST be v2

should probably be 

TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
(Continue reading)

Permalink | Reply | 0 comments |
headers
David A. Cooper | 6 Feb 2008 15:01
Favicon

encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.txt)


Jean-Marc Desperrier wrote:
>
> Paul Hoffman wrote:
>> At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>>> 4) Text was added to section 4.2.1.4 to provide further guidance on 
>>> the use of the explicitText string from the userNotice policy 
>>> qualifier:
>>>
>>>   The explicitText string SHOULD NOT include any control
>>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>>   the UTF8String encoding is used, all character sequences SHOULD be
>>>   normalized according to Unicode normalization form C (NFC) [NFC].
>> If we want all text to be normalized, we want it for both UTFString 
>> *and* BMPString.
> Would it not be better to simply deprecate BMPString ?
> (as well as UniversalString if referenced somewhere)

UniversalString is not an option.  explicitText is of type DisplayText, 
which is defined as follows:

   DisplayText ::= CHOICE {
        ia5String        IA5String      (SIZE (1..200)),
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

BMPString and VisibleString are already deprecated.  Here is the entire 
paragraph from which the new text was quoted.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Hoffman | 6 Feb 2008 16:38

Re: draft-ietf-pkix-rfc3280bis-11.txt


At 9:53 AM +0100 2/6/08, Jean-Marc Desperrier wrote:
>Paul Hoffman wrote:
>>At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>>>4) Text was added to section 4.2.1.4 to provide further guidance 
>>>on the use of the explicitText string from the userNotice policy 
>>>qualifier:
>>>
>>>   The explicitText string SHOULD NOT include any control
>>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>>   the UTF8String encoding is used, all character sequences SHOULD be
>>>   normalized according to Unicode normalization form C (NFC) [NFC].
>>If we want all text to be normalized, we want it for both UTFString 
>>*and* BMPString.
>Would it not be better to simply deprecate BMPString ?

No. Many people are just fine with BMPString, and it's pretty late in 
the process to make such a large change.

>(as well as UniversalString if referenced somewhere)

Ditto.

It is quite reasonable to try to make string changes in the next 
round, but there is likely to be a lot of disagreement on what to 
take out and why.

--Paul Hoffman, Director
--VPN Consortium
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman | 6 Feb 2008 17:21

Re: encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.txt)


At 9:01 AM -0500 2/6/08, David A. Cooper wrote:
>BMPString and VisibleString are already deprecated.  Here is the 
>entire paragraph from which the new text was quoted.
>
>   An explicitText field includes the textual statement directly in
>   the certificate.  The explicitText field is a string with a
>   maximum size of 200 characters.  Conforming CAs SHOULD use the
>   UTF8String encoding for explicitText, but MAY use IA5String.
>   Conforming CAs MUST NOT encode explicitText as VisibleString or
>   BMPString.  The explicitText string SHOULD NOT include any control
>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>   the UTF8String encoding is used, all character sequences SHOULD be
>   normalized according to Unicode normalization form C (NFC) [NFC].
>
>The sentence stating that CAs MUST NOT use VisibleString or 
>BMPString was added in draft -00 of 3280bis.

Whoops, sorry, missed that. No problem then.

(The really picky among us would say that you do not need to say 
"When the UTF8String encoding is used," because you can use NFC on 
pure ASCII text as a no-op, but that will cause some developers to 
pull in a full NFC library for nothing...)

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |
headers
Denis Pinkas | 7 Feb 2008 11:22
Picon

Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)


A few additional comments.

>> Neither X.509 nor extant 
>>PKIX standards define protocols for the management of trust anchors. 

RFC 3125 (issued in september 2001), which is an S-MIME document, defines 
a signature policy, which includes components for a validation policy. 
So there exists material, that could be re-used to address the narrower scope 
of a validation policy.

Some relevant text from RFC 3125 is copied below :

3.6.1  Certificate Requirements

   The certificateTrustTrees identifies a set of self signed
   certificates for the trust points used to start (or end) certificate
   path processing and the initial conditions for certificate path
   validation as defined RFC 2459 [7] section 4.  This ASN1 structure is
   used to define policy for validating the signing certificate, the
   TSA's certificate and attribute certificates.

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                               -- self-signed certificate
        pathLenConstraint       [0] PathLenConstraint   OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                                -- If not present "any policy"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane