yannick quenechdu | 6 Nov 17:58 2006

[SCVP] draft 28 - Basic Validation Algorithm Error


Hi,

The error is not explained, even if the heading of the error seems explicit.

3.2.4.2.2   Basic Validation Algorithm Error

 id-bvae-noValidCertPath      OBJECT IDENTIFIER ::= { id-bvae 4 }

Regards
--

-- 
Yannick Quenec'hdu
Architecte Sécurité/Security Architect
Tel : 01.58.18.68.28 - Mob: 06.24.73.32.43
Linagora SA
"Open Minds. Open Doors. Open Source."

tim.polk | 7 Nov 18:41 2006

Quick Survey on Algorithm OIDs in subject public key info


Folks,

I would like to conduct a *very* quick and dirty survey of CA and PKI client 
implementations.   I need to determine which algorithm OIDs are currently or 
soon to be supported in real implementations.  The ECC Design team is converging 
on a proposal, but we need to determine whether it is consistent with real 
implementations.

If possible, I need this information before tomorrow's PKIX meeting!  Rather 
than clog up the list, please send email to me directly.  I will summarize the 
results.

Here's what I need: please identify the implementation, including whether it is 
a client or CA.  If the information applies to an upcoming release, please give 
me a projected release date (quarter or year is fine).

For CAs:
Can your implementation assert the following Algorithm OIDs and the associated 
parameters in subject public key info of certificates?
-- from RFC 4055 --
id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }
-- from RFC 3279 --
id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 
   }
-- from ANSI X9.62-2005/X9.63-2006 and ecc-pkalgs-03 --
id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 
(Continue reading)

Stephen Kent | 7 Nov 22:32 2006
Picon

close of last call for 3280bis


We are long past the two-week WG last call time frame for 3280bis.

The list is essentially quiet re the document.

Hence I am declaring WG last call closed.

The authors should run I-D nits on the latest rev of this document in 
preparation for submissioon to the IESG.

Thanks,

Steve

Stefan Santesson | 8 Nov 02:10 2006
Picon

Wanted - presentations for the PKIX meeting


All of you that are listed to hold presentations during the PKIX
meeting:
http://www3.ietf.org/proceedings/06nov/agenda/pkix.txt

Please provide me with presentation material prior to the meeting so I
can post it on the materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

David A. Cooper | 8 Nov 20:01 2006

Re: The definition of OtherName in 3280bis differs with X.509?

I do not understand ASN.1 well enough to answer the question below, but someone else on the PKIX mail list may be able to respond.

I can say, however, that the ASN.1 for OtherName in 3280bis is the same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 (April 2002), so if it in an error it is a very old error.

Dave


-------- Original Message -------- Subject: Date: From: To:
The difinition of OtherName in 3280bis differs with X.509?
Wed, 08 Nov 2006 14:23:38 +0800
赵 敏 <qzzm <at> hotmail.com>
david.cooper <at> nist.gov


Hello David: In rfc3280bis,Setion 4.2.1.6: OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } Setion A.2 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax AnotherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } But in X.509(2005),Setion 4.2.1.6: GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OTHER-NAME ::= TYPE-IDENTIFIER In X.681(2002),Annex A: A.2 The TYPE-IDENTIFIER information object class is defined as: TYPE-IDENTIFIER ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } WITH SYNTAX {&Type IDENTIFIED BY &id} X.681(2002),Annex C The instance-of type: C.7 The associated sequence type shall be: SEQUENCE { type-id <DefinedObjectClass>.&id, value [0] <DefinedObjectClass>.&Type } where "<DefinedObjectClass>" is replaced by the particular "DefinedObjectClass" used in the "InstanceOfType" notation. So,INSTANCE OF OTHER-NAME associated sequence type shall be: OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } But,this is associated sequence type,not the encoding rules.The definition of BER/DER is in X690. In X690(2002),Setion 8.16 Encoding of an instance-of value 8.16.1 The encoding of the instance-of type shall be the BER encoding of the following sequence type with the value as specified in 8.16.2: [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id <DefinedObjectClass>.&id, value [0] EXPLICIT <DefinedObjectClass>.&Type } where "<DefinedObjectClass>" is replaced by the particular "DefinedObjectClass" used in the "InstanceOfType" notation. So,I think the definition of OtherName in the '88 ASN.1 syntax should be: OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } Because the tag of otherName is IMPLICIT,the encode value of GeneralName in rfc3280bis is identical of X.509. zhaomin
Alan Sill | 8 Nov 23:46 2006
Picon

List invitation: OGSA-AuthN-BoF for grid services authentication issues


This is the last in a series of messages intended to announce a
requested Birds-of-a-Feather  session (BoF) at the Open Grid Forum
OGF-19 meeting for discussion of Open Grid Services Architecture
Authentication topics and activities.  The list and its associated
BoF are intended to carry out the steps for formation of an OGSA-
AuthN work group.  This message is being sent out widely to call your
attention to the existence of a mailing list specific to this purpose.

You may subscribe to the ogsa-authn-bof <at> ogf.org mailing list by
sending a message to me or to David Groep <davidg <at> nikhef.nl> , or by
visiting the following page:

http://www.ogf.org/mailman/listinfo/ogsa-authn-bof

Your participation is appreciated.  This announcement will be sent to
several relevant lists and people to extend the invitation as broadly
as possible, but subsequent communication about the BoF will proceed
through the above list.  Subscription to the above list will be your
method to ensure involvement in this process.

Best,

Alan Sill, Ph.D
TIGRE Senior Scientist
High Performance Computing Center
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: Alan.Sill <at> ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

--
   ogsa-authz-wg mailing list
   ogsa-authz-wg <at> ogf.org
   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

Stephen Kent | 9 Nov 04:43 2006
Picon

draft meeting minutes

Please send comments to me by 11/27.

Steve
-----

PKIX WG Meeting 11/8/06

Edited by Steve Kent
Chairs: Stephen Kent <kent <at> bbn.com> &  Stefan Santesson <stefans <at> microsoft.com>

The PKIX WG met once, for a total of two hours, during the 67th IETF. A total of approximately 50 individuals participated in the meeting.


Document Status Review - Stefan Santesson (Microsoft)
       Two new RFCs issued: SIM and Update to Directory String Processing in RFC 3280. Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed for the first two, and a revised I-D is needed for CMC. (Russ Housley requested WG direction re the UI draft. This individual submission received AD comments requesting changes, but no revised document has been delivered to the IESG.) Two documents have completed WG last call, and will soon be forwarded to the IESG: 3280bis and SAN for Service Names. Two documents still under WG review: ECC algorithms (waiting for resolution of algorithm parameter resolution) and the Draft for ECDSA and DSA with SHA-2. (slides)
 
     
     
PKIX WG Specifications

3280bis -  David Cooper (NIST)
      A new draft 05 was recently posted as response to past WG last call. David reviewed the changes made from version 4 to version 5, and provided an explanation for each change. (slides)

Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)
  This document is still in AD evaluation and a new draft requested by the AD. We are currently at version 28! Tim reviewed the changes made in response to Sam's comments. He noted that these changes were posted to the list on Halloween, and that there have been no responses to this posting. However, Tim identified one or two additional fixes that need to be effected before the document will be finished. He also identified one open issue, related to whether the document satisfies the interoperability requirements established by 2026.
       [Sam wants us to run a straw poll to confirm that the WG is comfortable with a single spec that defines both DPD and DPV and does not mandate that a server do either one as a base.]
(slides)

Certificate Management Messages over CMS (CMC) - Jim Schaad (Soaring Hawk Consulting)
      These documents are under IESG review which has resulted in several change requests. For example, there is a need for the section detailing the changes from the base documents (since this is a "bis" document). There is also a need to accommodate hash algorithm agility, a relatively easy fix. A bigger issue is whether to change the OID used to refer to the encrypted data, because of the way S/MIME has defined this OID. A more significant issue is a request from the AD to make use of CRMF a MUST and make use of PKCS #10 structures a MAY. We plan to complete WG last call by December, in parallel with AD re-review. (slides)

Algorithm IDs for Elliptic Curve Cryptography in PKIX - Brian Minard (Certicom)
      Dan Brown (the document author) could not be physically present, but monitored the presentation via Jabber. Looking for feedback on several issues, including support for parameters for SHA-2, and references to KDFs to be used with the public key in the certificate, in the context of EC-DH or EC-MQV. The question was raised as to why one needs to make reference to a KDF in a certificate, given that the KDFs are not protocol specific, but one needs protocol-specific details to completely specify how key derivation is performed. Much of the discussion on this topic is subsumed by the next topic. (slides)

Design team report on ECC public key IDs - Tim Polk (NIST)
      We instantiated a design team of Tim, Brian Minard, and Tolga Acar to address this complex issue. RFC 3279 defines an OID for EC, and includes algorithm parameters, but this does not provide a way to distinguish between a bit string to be used with EC-DH vs. EC-MQV. Two choices were evaluated: RFC 4055-style solution vs. the ANSI X.962 solution to specify which algorithm or algorithms can be used with the key. RFC 4055 was developed to distinguish among RSA modes, but is easily adapted to accommodate ECC. ANSI X.962 puts into the parameters field the additional info needed to specify the algorithms that the key can be used with. This leads to potential nesting of OIDs, and one can also specify KDFs here as well. The design team suggested a third approach, namely to retain the 3279 parameter model, and to optionally augment it with a certificate extension to specify the additional data that the ANSI approach encodes in the parameters field, as well as accommodating the notion of family OIDs, something not supported in the ANSI approach. A feature of this approach is that if the extension is non-critical, the result is backwards compatible with 3279, but making it critical allows one to enforce the sort of fine-grained controls available in the ANSI approach. The team developed a set of criteria for evaluating the 3  approaches. They polled a variety of folks and got a diverse set of answers. Their decision was that the use of a new extension is preferred, in conjunction with the RFC 3279 ECC syntax. Numerous questions were raised by attendees. The discussion will continue on the list, and we will probably result in a new work item to resolve this issue, including asking whether the use of a new extension is appropriate for RSA as well (in lieu of RFC 4055). (slides)


Related Specifications & Liaison Presentations
     

Validation Certificates in CRLs - Stefan Santesson (Microsoft)
      A new individual draft that proposes an optional extension that allows one to embed one or more certificates in a CRL. The intent is to facilitate CRL validation when the certificate(s) needed to verify a CRL are different from the certificate associated with the CA under whose auspices the CRL is issued. One can already embed a pointer to the requisite certificate, so the advantage to this approach is that it can save a retrieval request (across a net), and for CRL validation in the NR context, when CRL processing will take place long after CRL issuance. One should use this extension only in "appropriate" contexts, e.g., to avoid unnecessary CRL bloat. The question is whether this be accepted as a WG document. A straw poll will be conducted on the WG list. (slides)
Wen-Cheng Wang | 9 Nov 06:41 2006
Picon

Re: The definition of OtherName in 3280bis differs with X.509?

It is true that an INSTANCE OF <DefinedObjectClass> is equivalent to
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id     <DefinedObjectClass>.&id,
    value        [0] EXPLICIT <DefinedObjectClass>.&Type
}
 
Therefore, if the "AnotherName" type is, as claimed, defined to replace
the "INSTANCE OF OTHER NAME" type, its syntax should be:
 
AnotherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id      OBJECT IDENTIFIER,
    value        [0] EXPLICIT ANY DEFINED BY type-id
}
 
(Note that in RFC 2459, 3280 and 3280bis, the text wrongly claims
that "AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER".
The reason why the statement is wrong is that OTHER-NAME
is an information object class while AnotherName is a data type, and
a data type can not replace an information object class.
The correct way of saying that should be "AnotherName replaces
INSTANCE OF OTHER-NAME", because "INSTANCE OF OTHER-NAME"
is a data type.)
 
However, to my knowledge of ASN.1, since the default tagging mode of the
PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be the
same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede the
SEQUENCE type. The reason is that the outer implicit tag (i.e., the tag [0]
precedes the "AnotherName" type in the GeneralName type) will always
overwrite the inner tag no matter the inner tag is an "[UNIVERSAL 8] IMPLICIT
SEQUENCE" or  simply a "SEQUENCE".
 
My conclusion to this issue is that even the syntax is inconsistent between
PKIX and ITU-T X.509, it is luckly that their DER encodings will still be the
same.
 
Nevertheless, one thing we should note is that the "AnotherName" type should
not be used alone without any implicit tag precede, otherwise it will result
inconsistent DER encoding with ITU-T X.509. For example, if someday we
define a type named "ListOfAnotherNames" as the following:
 
ListOfAnotherNames ::= SEQUENCE OF AnotherName
 
With our current definition of the "AnotherName" type, the DER encoding
of an "AnotherName" value will different with the case where it is defined
as the following:
 
ListOfAnotherNames ::= SEQUENCE OF INSTANCE OF OTHER-NAME
 
So, now the question is "do we need to change the syntax of AnotherName
to be syntactically aligned with ITU-T X.509?"
 
Wen-Cheng Wang
----- Original Message -----
To: 赵 敏
Cc: pkix
Sent: Thursday, November 09, 2006 3:01 AM
Subject: Re: The definition of OtherName in 3280bis differs with X.509?

I do not understand ASN.1 well enough to answer the question below, but someone else on the PKIX mail list may be able to respond.

I can say, however, that the ASN.1 for OtherName in 3280bis is the same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 (April 2002), so if it in an error it is a very old error.

Dave


-------- Original Message -------- Subject: Date: From: To:
The difinition of OtherName in 3280bis differs with X.509?
Wed, 08 Nov 2006 14:23:38 +0800
赵 敏 <qzzm <at> hotmail.com>
david.cooper <at> nist.gov


Hello David: In rfc3280bis,Setion 4.2.1.6: OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } Setion A.2 -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax AnotherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } But in X.509(2005),Setion 4.2.1.6: GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OTHER-NAME ::= TYPE-IDENTIFIER In X.681(2002),Annex A: A.2 The TYPE-IDENTIFIER information object class is defined as: TYPE-IDENTIFIER ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } WITH SYNTAX {&Type IDENTIFIED BY &id} X.681(2002),Annex C The instance-of type: C.7 The associated sequence type shall be: SEQUENCE { type-id <DefinedObjectClass>.&id, value [0] <DefinedObjectClass>.&Type } where "<DefinedObjectClass>" is replaced by the particular "DefinedObjectClass" used in the "InstanceOfType" notation. So,INSTANCE OF OTHER-NAME associated sequence type shall be: OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } But,this is associated sequence type,not the encoding rules.The definition of BER/DER is in X690. In X690(2002),Setion 8.16 Encoding of an instance-of value 8.16.1 The encoding of the instance-of type shall be the BER encoding of the following sequence type with the value as specified in 8.16.2: [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id <DefinedObjectClass>.&id, value [0] EXPLICIT <DefinedObjectClass>.&Type } where "<DefinedObjectClass>" is replaced by the particular "DefinedObjectClass" used in the "InstanceOfType" notation. So,I think the definition of OtherName in the '88 ASN.1 syntax should be: OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } Because the tag of otherName is IMPLICIT,the encode value of GeneralName in rfc3280bis is identical of X.509. zhaomin
Denis Pinkas | 9 Nov 15:17 2006
Picon
Picon

Comment on draft-santesson-pkix-vccrl-00.txt


Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on the CA side and 
on the relying party side and the saving of  one exchange.

Denis

Russ Housley | 9 Nov 19:06 2006

Re: draft meeting minutes

Dear PKIX WG:

Document Status Review - Stefan Santesson (Microsoft)
        Two new RFCs issued: SIM and Update to Directory String Processing in RFC 3280. Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed for the first two, and a revised I-D is needed for CMC. (Russ Housley requested WG direction re the UI draft. This individual submission received AD comments requesting changes, but no revised document has been delivered to the IESG.)

This is draft-choi-pkix-ui-03.txt.
It is not a PKIX WG document, but the authors have not responded to messages from me.  I am going to drop it if the authors do not respond soon.  If the PKIX WG thinks there is value in this document, I'll send it to the WG instead of dropping it.

Russ

Gmane