headers
Operator - SUNTAN | 1 Nov 1997 09:00

Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "listserv <at> tandem.com"
(NOT ietf-pkix <at> tandem.com):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at wford <at> verisign.com  
                             or 
                Jean Pawluk at pawluk_jean <at> tandem.com.

If you have any questions about this list service in general, you
can contact postmaster <at> tandem.com.
Permalink | Reply | 0 comments |
headers
PAWLUK_JEAN | 3 Nov 1997 00:30

Reminder: How to unsubscribe yourself from ietf-pkix

Please use the listserv <at> tandem.com address !

If you ever want to remove yourself from this mailing list,
send the following command in email to "listserv <at> tandem.com"
(NOT ietf-pkix <at> tandem.com):

    unsubscribe <your e-mail-id> ietf-pkix

Example

    Your email address is blue.green <at> red.com in the body of your
    letter include the following :

    unsubcribe blue.green <at> red.com ietf-pkix

    Then mail it to listserv <at> tandem.com
Permalink | Reply | 0 comments |
headers
Rich Ankney | 3 Nov 1997 01:59
Picon

Re: Object Identifiers: Confusion now hath made his masterpiece

I'm the one who registered md<x>WithRSASignature.  RSASignature is
the ANSI X9.31 version of RSA, which is the same as ISO 9796-2.
The padding rules are different from PKCS #1 although I can't see that
they provide any more security.

X9.31 got derailed several years ago during the PKP brouhaha and
is only now going out for ballot.

It was easy to register these OIDs since I chaired the OIW Security SIG
at the time.  I have NO idea where the OIW sha1WithRSAEncryption
came from; it's not in any of the OIW agreements I've seen...

Regards,
Rich

----------
> From: Peter Gutmann <pgut001 <at> cs.auckland.ac.nz>
> To: ietf-pkix <at> tandem.com
> Subject: Re: Object Identifiers: Confusion now hath made his masterpiece
> Date: Sunday, November 02, 1997 11:19 PM
> 
> [Followups trimmed somewhat]
>  
> >>1. DSA and SHA combinations have multiple redundant definitions (X9.57,
some
> >>   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
> >It depends on what standard you choose to follow.
>  
> <rant humour=on>
> It seems to me that the designers of some of these standards are like WWI
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Nov 1997 05:19
Picon
Picon
Picon
Favicon

Re: Object Identifiers: Confusion now hath made his masterpiece

[Followups trimmed somewhat]

>>1. DSA and SHA combinations have multiple redundant definitions (X9.57, some
>>   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
>It depends on what standard you choose to follow.

<rant humour=on>
It seems to me that the designers of some of these standards are like WWI
generals who sit 50 miles behind the front in a French chateau moving figures
around on a board while the poor implementors are stuck in the trenches, up to
their eyeballs in mud and trying to figure out which one of a dozen different
OIDs they need to use to provide the greatest chance that Webscape Netvigator
and Micronet Exploder will accept the output from their software, while
barrages of management directives to get the product out on time go thundering
overhead...
</rant>

(That was meant to be humour, for all the standards designers who are even now
reaching for their flamethrowers).

>[OIW OIDs in the 1 3 14 arc]

I knew where the OIDs came from, I was more concerned with what standing they
have in practice (thus the comment about "strange OIDs which don't make much
sense").  For example the usual OIDs used for RSA with a hash function are the 
PKCS #1 ones, however there are also OIW OIDs for mdxWithRSA, and then also 
md4WithRSAEncryption which changes to ...WithRSASignature by the time we get 
to MD5.  Does anyone use any of these OIDs?  Then there are OIDs for the 
deprecated square-mod-N hash function, some deprecated DSA OIDs (eg the 
dsaCommon... ones), ambiguous OIDs like rsa (1 3 14 3 2 1 1) which doesn't
(Continue reading)

Permalink | Reply | 2 comments |
headers
jsanders | 3 Nov 1997 08:07

IETF-PKIX Mail List Notice


Attention, Listserv <at> tandem.com Users,

Due to operational exigencies, we at Tandem.com have
replaced the old mail system with a new one.  This
has temporarily affected the e-mail list service in
that the administrative commands no longer work.

A new list server package is on order and we expect
to install it soon.  It will provide functionality
equal to and beyond the old listserver system.

In the meantime your requests can be submitted
to "listserv <at> tandem.com", which has been aliased
to postmaster and the postmaster team will
fill your requests manually as they are
received.

Thank you,
listserv <at> tandem.com
Permalink | Reply | 0 comments |
headers
John Pawling | 3 Nov 1997 17:53

PKIX 1 Comment

All:

In the 14 Oct PKIX X.509 Certificate and CRL Profile, Appendix A and B
please replace:

Attribute       ::=     SEQUENCE {
        type    AttributeValue,
        values  SET OF AttributeValue}

with:

Attribute       ::=     SEQUENCE {
        type    AttributeType,
        values  SET OF AttributeValue}

================================
John Pawling   
jsp <at> jgvandyke.com                             
J.G. Van Dyke & Associates, Inc.           
================================
Permalink | Reply | 0 comments |
headers
John Pawling | 3 Nov 1997 18:19

PKIX 1 Examples Comments

All,

The 14 Oct PKIX X.509 Certificate and CRL Profile, Section 7.2.2 states "The
id-dsa-with-sha1 algorithm syntax has NULL parameters."  Furthermore, the
X9.57 spec (which defines the id-dsa-with-sha1 OID used in PKIX 1) states
that NULL parameters shall be used with id-dsa-with-sha1.  In summary, both
specs state that the AlgorithmIdentifier parameters shall be NULL when the
AlgorithmIdentifier algorithm field is id-dsa-with-sha1.

PKIX 1, Appendix D.1.1 includes an ASN.1 dump of a "self-signed"
Certificate.  The ASN.1 dump indicates that the id-dsa-with-sha1 OID is
present in the SIGNED Macro and signature AlgorithmIdentifier algorithm
fields, but in both locations the AlgorithmIdentifier parameters are absent.
The specs state that they shall be NULL which implies that they are present
and encoded as NULL (05 00), so the example is wrong because it indicates
that the parameters are absent.

Also, Appendices D.1.2, D.2.1, D.2.2, and D.4 do not include the NULL
parameters in conjunction with the id-dsa-with-sha1 OID.

Recommend that these examples should be corrected or that the specs should
be changed to state that the AlgorithmIdentifier parameters shall be absent
(rather than NULL) when the AlgorithmIdentifier algorithm field is
id-dsa-with-sha1.

================================
John Pawling   
jsp <at> jgvandyke.com                             
J.G. Van Dyke & Associates, Inc.           
================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
David P. Kemp | 5 Nov 1997 21:51

Re: PKIX 1 Example 1


Appendix D.1, the Self-Signed certificate, includes a basicConstraint
extension, which has the value "30 00" - an empty sequence. Since cA
defaults to FALSE, this example is a self-signed end-entity cert -- not
a particularly useful thing to have lying around :-).

I'll take an action item to generate a corrected example with cA = TRUE.
Permalink | Reply | 0 comments |
headers
Bob Jueneman | 6 Nov 1997 00:00
Picon
Favicon

PKIX Part 1 Invalidity date

Paragraph 5.3.3 Invalidity date (of CRLs) is ambiguous and potentially
misleading. It says:

"The invalidity date is a non-critical CRL entry extension that provides the
date on which it is know or suspected that the private key was compromised
or that the certificate otherwise became invalid. This date may be earlier
than the revocation date in the CRL entry, but must be later than the issue
date of the previously issued CRL."

As written, this could be read as the date when the key was really
compromised (or was allegedly compromised).  Since the discovery of the
compromise might occur a long time after the compromise itself, if the time
between CRLs is sufficiently long this might permit retroactive repudiation.

I would suggest that the language be changed to read "...provides the date
on which a compromise BECAME KNOWN, OR CAME TO BE SUSPECTED, or that the
certificate otherwise became invalid." 

It does very little good to tell someone well after the fact that someone's
keys may have been compromised, except to try to set the stage for
repudiating a transaction which has become odious.

The fact (or claim) that someone's keys might have been compromised, even if
proved, does NOT necessarily mean that the authorized user of the keys
didn't sign the transaction, it only means that someone else might have. 
The consequences depend largely on emerging state and international law as
to who has what burden of proof in such instances, and independent of who
has the burden of proof, who bears the liability if the signature is
successfully disavowed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 6 Nov 1997 00:19
Picon
Favicon

PKIX Part 1 -- CRL reason codes

Section 5.3.1 provides a list of CRL reason codes, which I would like to see
clarified considerably.

The affiliationChanged would seem to include someone who has changed
companies, but it would be unusual language to describe someone who no
longer had a particular role, such as a purchasing agent, or whose title had
changed.

In the case of a residential person, the affiliationChanged would seem to
come to closest to the case where someone has changed their name, either
through marriage or otherwise, or who has changed their address, or maybe
even changed their ISP and/or CA.

The specific semantics of this CRLReason need to be spelled out in
considerably more detail.

There would seem to be a potential overlap and ambiguity in the case of an
affiliationChange and a superseded certificate.  Assuming that someone stays
within a given company, but merely changes departments, or internal mailing
address, etc., which usage should apply when a new certificate is issued? 
Likewise, what should happen if someone changtes their name but keeps the
same public/private keypair?

Under what circumstances is there an obligation to revoke a certificate in
the event a new certificate is issued, and why?  What are the semantics with
regard to the new certificate including the same public key as the old one?

If the "unspecified" reason code is being deprecated in favor of simply not
including the reason code in the first place, why is it even being defined?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane